Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix go-gitea#22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

For a long time Gitea has tested PR patches using a git apply --check
method and in fact prior to the introduction of a read-tree assisted
three-way merge in go-gitea#18004, this was the only way of checking patches.

Since go-gitea#18004, the git apply --check method has been a fallback method,
only used when the read-tree method has detected a conflict. The
read-tree assisted three-way merge method is much faster and less
resource intensive method of detecting conflicts. go-gitea#18004 kept the git
apply method around because it was thought possible that this fallback
might be able to rectify conflicts that the read-tree three-way merge
detected. I am not certain if this could ever be the case.

Given the uncertainty here and the now relative stability of the
read-tree method - this PR makes using this fallback optional and
disables it by default. The hope is that users will not mention any
significant difference in conflict detection and we will be able to
remove the git apply fallback in future, and/or improve the read-tree
three-way merge method to catch any conflicts that git apply method
might have been incorrectly detecting.

(See go-gitea#22083)

Ref go-gitea#22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix #22083

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>

Backport go-gitea#22118

Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix go-gitea#22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

Backport go-gitea#22118

Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix go-gitea#22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

Backport #22118

Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix #22083

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>

Backport #22118

Moved files in a patch will result in git apply returning:

```
error: {filename}: No such file or directory
```

This wasn't handled by the git apply patch code. This PR adds handling
for this.

Fix #22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>

For a long time Gitea has tested PR patches using a git apply --check
method, and in fact prior to the introduction of a read-tree assisted
three-way merge in #18004, this was the only way of checking patches.

Since #18004, the git apply --check method has been a fallback method,
only used when the read-tree three-way merge method has detected a
conflict. The read-tree assisted three-way merge method is much faster
and less resource intensive method of detecting conflicts. #18004 kept
the git apply method around because it was thought possible that this
fallback might be able to rectify conflicts that the read-tree three-way
merge detected. I am not certain if this could ever be the case.

Given the uncertainty here and the now relative stability of the
read-tree method - this PR makes using this fallback optional and
disables it by default. The hope is that users will not notice any
significant difference in conflict detection and we will be able to
remove the git apply fallback in future, and/or improve the read-tree
three-way merge method to catch any conflicts that git apply method
might have been able to fix.

An additional benefit is that patch checking should be significantly
less resource intensive and much quicker.

(See
#22083)

Ref #22083

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>

Backport go-gitea#22130

For a long time Gitea has tested PR patches using a git apply --check
method, and in fact prior to the introduction of a read-tree assisted
three-way merge in go-gitea#18004, this was the only way of checking patches.

Since go-gitea#18004, the git apply --check method has been a fallback method,
only used when the read-tree three-way merge method has detected a
conflict. The read-tree assisted three-way merge method is much faster
and less resource intensive method of detecting conflicts. go-gitea#18004 kept
the git apply method around because it was thought possible that this
fallback might be able to rectify conflicts that the read-tree three-way
merge detected. I am not certain if this could ever be the case.

Given the uncertainty here and the now relative stability of the
read-tree method - this PR makes using this fallback optional but
enables it by default. A `log.Critical` has been added which will alert
if the `git apply --check` method was successful at checking a PR that
`read-tree` failed on.

The hope is that none of these log.Critical messages will be found and
there will be no significant difference in conflict detection. Thus we
will be able to remove the git apply fallback in future, and/or improve
the read-tree three-way merge method to catch any conflicts that git
apply method might have been able to fix.

An additional benefit for anyone who disables the check method is that
patch checking should be significantly less resource intensive and much
quicker.

(See
go-gitea#22083)

Ref go-gitea#22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

)

Backport #22130

For a long time Gitea has tested PR patches using a git apply --check
method, and in fact prior to the introduction of a read-tree assisted
three-way merge in #18004, this was the only way of checking patches.

Since #18004, the git apply --check method has been a fallback method,
only used when the read-tree three-way merge method has detected a
conflict. The read-tree assisted three-way merge method is much faster
and less resource intensive method of detecting conflicts. #18004 kept
the git apply method around because it was thought possible that this
fallback might be able to rectify conflicts that the read-tree three-way
merge detected. I am not certain if this could ever be the case.

Given the uncertainty here and the now relative stability of the
read-tree method - this PR makes using this fallback optional but
enables it by default. A `log.Critical` has been added which will alert
if the `git apply --check` method was successful at checking a PR that
`read-tree` failed on.

The hope is that none of these log.Critical messages will be found and
there will be no significant difference in conflict detection. Thus we
will be able to remove the git apply fallback in future, and/or improve
the read-tree three-way merge method to catch any conflicts that git
apply method might have been able to fix.

An additional benefit for anyone who disables the check method is that
patch checking should be significantly less resource intensive and much
quicker.

(See
#22083)

Ref #22083

Signed-off-by: Andrew Thornton <art27@cantab.net>

<!--

Please check the following:

1. Make sure you are targeting the `main` branch, pull requests on
release branches are only allowed for bug fixes.
2. Read contributing guidelines:
https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md
3. Describe what your pull request does and which issue you're targeting
(if any)

-->

Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>